The advent of time-shared, multi-user graphical systems gave individual users the ability to interact simultaneously with a single computer system or workstation. For example, in the 1970s, Unix® with X Windows allowed users, e.g., system administrators, to interact simultaneously with the computer system as a “normal user” or a “super user” using any number of windows on a single desktop (“desktop sharing”) of the computer system. Typically, minimal privileges were given to a normal user interacting with the computer system, whereas a full set of privileges were given to a super user to maintain and configure the computer system. Separate windows could be used for operating as a normal user and a super user. Generally, to determine if a particular window or interaction area was designated for a normal user or a super user, the user had to make explicit queries, such as “whoami” queries. A disadvantage of these types of systems is that they lack a clear indication of the context regarding the operation of the user. Furthermore, making explicit queries to determine the context of a user's activity hampers work productivity and does not assure the return of correct information.
Thus, operating as multiple users on prior desktop sharing systems can be problematic due to the lack of a clear denotation for each window or user interaction area. For instance, these systems did not discriminate whether a window was supporting a normal user with minimal privileges or a super user with a full set of privileges. Nevertheless, despite the lack of a clear denotation for each window, advanced users could perform multiple tasks as multiple users in multiple windows without error, but this required careful operation and knowledge of the context for each window to perform the desired task. Otherwise, an inadvertent error could result such as deletion of files due to a command executed in a window with a full set of privileges.
Modern operating systems, such as the Microsoft Windows® family of operating systems, also provide desktop sharing. In particular, Microsoft Windows XP® allows a display to support simultaneously multiple desktops, with only one being displayed at time. A user can switch between the desktops with any combination of keyboard sequences. A number of disadvantages exist for these types of systems that provide separate desktops for different user contexts. For instance, switching between different desktops or having a desktop in a window is not very clear, nor scalable, as each desktop is similar to each other, which can also be similar to the user's original desktop. Moreover, each desktop is disjointed and not integrated into the user's original desktop. This is cumbersome and awkward to the user, eliminating otherwise available functionality that hinders the user's ability to perform operations.
Other graphical operating systems and platforms have also used portions of the desktop for activity separate and distinct from the regular environment of a user. For example, remote-access software such as PCAnywhere emulates an entire desktop within a single window on a display of a remote computer system. Likewise, virtual machine software such as Vmware emulates a desktop similar to PCAnywhere. However, these modern operating systems discourage users from operating as multiple users to avoid user confusion. That is, users are encouraged to work exclusively as one user on the computer system.
One technology that also provides for desktop sharing is Java applets. Java applets are programs that can be sent along with a Web page to a user. These programs can perform, e.g., interactive animations, immediate calculations, or other simple tasks without having a user send a request back to a server. Unfortunately, Java applets may originate from untrusted, or even hostile, Web pages. Therefore, their use should be suspect and restricted for purposes of security. In particular, Java applets should be restricted from persistently affecting a user's sensitive data. Sensitive data such as passwords should not be entered within a Java applet window.
A Java applet window can be marked as an “Untrusted Applet Window,” which is to remind users not to enter sensitive data. However, using markings provided by Java's “Untrusted Applet Window” fails to be universal or scalable. That is, it functions only for the limited set of applications designed and implemented as Java applets, and, for each of those, shows the same type of alert message, regardless of the applet's context. In addition, the type of marking provided by Java can be tampered with, either inadvertently or maliciously, by non-Java-applet activity on a computer system, e.g., through user actions.
Today, with the availability of desktop sharing systems, a user can perform a variety of different types of activities that have distinctly different relationships with the user's environment. For example, the user can perform activities intended for a corporate or home environment, which produce different types of user interactions and activities. For instance, in a home environment, the user may wish to view Web pages or emails without affecting their environment. In a corporate environment, the user may desire to try new software, installing it on a trial basis, with the intent to revert all of its effects. Furthermore, in a corporate environment, the user may wish to share or link information with other users through “extranets” or “peer-to-peer services.” Thus, segregating, limiting, and modifying the potential effects of such activities are desired on desktop sharing systems.
User accounts can limit the effects of activities by different users to that intended and expected by the users on desktop sharing systems. In particular, user accounts encapsulate the information particular to each individual user, such as the user's name, password, area of transient and persistent storage, configuration information, resource-usage quotas and other properties to be enforced on the user's behavior. By using user accounts, time sharing could be implemented without compromising the systems usability. Whereas previous computer system operations always directly affected the global state of the machine, operations on a user's behalf in systems implementing user accounts typically affect only the information in the user's account. In this manner, each user's actions became isolated from other users since, for the most part, they only affected the individual user's account information.
FIG. 1 illustrates the components in a conventional computer system 100 implementing user accounts. Each operation that involves accessing the state of the system is discriminated to determine if the state being accessed is local to an individual user account or global to the entire system (and therefore shared between all user accounts). If access is to a user-local state, the discrimination procedure determines the context of the access operation, that is, which user's account information to access. In conventional systems, context may be determined by, for example, using a low-level indirection (for memory accesses), the current virtual memory page tables, or a user account reference in each process or thread control block (for system calls).
Thus, user accounts can be very useful. They enhance usability when multiple individuals simultaneously use a computing system and allow for segregation of system activity based on intent. For example, conventional systems may use a supervisor user account, called “root,” to run background services. Also, web-server activities may operate as “nobody,” that is, a user account with very limited privileges. Additionally, user accounts are integral to maintaining the security of a multiple user computer system since they may be used to control which data a user may access or actions a user may perform.
Furthermore, as disclosed in co-pending and commonly owned U.S. patent application Ser. No. 10/144,048, entitled “METHODS AND SYSTEMS FOR USING DERIVED USER ACCOUNTS,” filed May 10, 2002, which is incorporated herein by reference, derived user accounts (“DUAs”) can also limit the effects of activities by different users to that intended and expected by the users. DUAs are essentially identical to a user's normal working environment, and are designed to enable non-expert users to align their actions with desired intent and potential effects. In particular, DUAs are generated from user accounts in which a DUA is linked to an existing original user account (“OUA”). By using a DUA, its linked OUA may be selectively isolated from system operations. Thus, an advantage of using DUAs is that they are derived from the user's actual environment, and can be arbitrarily integrated with that environment. This enhances the user's ability to work more productively and instinctively with the workstation or desktop. Yet, even using DUA's, there is still no clear denotation or indication that a user is operating within a particular DUA.
Various graphical systems have been proposed, as described in U.S. Pat. No. 6,323,884 and U.S. Pat. No. 5,377,317, to address limited aspects of helping users coordinate their actions in graphical interaction systems. More particularly, graphical systems have been designed, as described in U.S. Pat. No. 5,760,769 and U.S. Pat. No. 5,790,127, that focus on helping users avoid confusion when performing “application sharing” such as when users interact with windows representing activity on remote computers connected, e.g., via teleconferencing with the user's desktop graphical interaction area or in a window. Although teleconferencing application sharing mechanisms can mark the teleconferencing application, these systems do not mark the user's other applications, only those connected via teleconferencing, and do not provide scalability for other types of contexts. In addition, these mechanisms suffer from the same lack of assurance as Java's applet mechanisms. Furthermore, such systems do not clearly or consistently denote and circumscribe different types of activity, nor do they implement mechanisms to limit the effects of the different types of activity without specific tailoring of the applications.
Therefore, as users operate in different environments, it is important that the context of a user's activity be clearly and unambiguously marked in order to provide the users with an indication on how to interact within a particular activity. Thus, there is a need for clear denotation of application semantics, as a user bases interactions with a desktop application based on the context of those applications, i.e., their semantics.